Projet

Général

Profil

Réflexions fonctionnelles sur le mode guichet et critiques de l'existant

  • L'idée est de se mettre d'accord sur des besoins fonctionnels avant de faire des wireframes.
  • Tout le long, je parle de welco, étant entendu qu'il s'agit du mode guichet intégré dans Combo.
  • Par ailleurs, dans ce doc je souligne essentiellement ce qu'il convient d'améliorer (et donc le doc est très critique par rapport à l'existant). Ceci dit, l'existant fonctionne et remplit son rôle, il convient donc se faire attention à ne pas régresser (d'un point de vue ergonomique , l'écran welco actuel est perturbant au début mais permet finalement aux agents de traiter les demandes existantes).
  • Les commentaires ci-dessous sont basés sur l'expérience de Grenoble2, mais il serait vraiment intéressant que les CPF utilisant Welco viennent compléter ce doc avec leur propre expérience.
  • En complément, des éléments de cas d'usage sont présents ici sur la page Rochefort : https://dev.entrouvert.org/projects/rochefort/wiki/Mise_en_place_de_la_brique_multi-canal

Limites du fonctionnement actuel : remarques basées sur l'expérience de Grenoble

  • La recherche usager
    • Lorsque aucun compte usager n'a été précédemment créé, Welco actuel ne permet pas de rechercher un usager sur la base de son nom, du N° de la demande ou même du N° de suivi
    • Il faudrait permettre une recherche sur l'ensemble des démarches, y compris celles réalisées par des usagers sans compte (nom, tel, code de suivi, N° de la demande, le mail...)
    • et utiliser une recherche telle zoo (plus puissante pour retrouver un usager sur nom approchant)
  • Autres points soulevés :
    • Il faudrait pouvoir intégrer des référentiels adresse dans la procédure de création de compte lorsque la collectivité l’exige sur les formulaires citoyen [note Brice : question plus globale que Welco = utilisation d'un référentiel dans les attributs d'un compte]
    • Mettre en cohérence les éléments constitutifs de compte usager dans Welco avec ceux qui sont paramétrés, si non c'est inutilisable
    • Welco doit également être compatible avec un mode multi-collectivités (normalement fin mars pour GL)

Réflexions sur le fonctionnement souhaité (scénario)

Un usager appelle ou vient au guichet, soit pour une nouvelle démarche, soit pour le suivi d'une démarche existante (cas sans liaison avec CTI)

Trouver ce que l'on cherche

Des critères de recherche élargis :
  • Nom, prénom, mobile, tel fixe, mail, date naissance, N° de demande, code de suivi...

La recherche va renvoyer 2 types de résultats qui pourraient présenter dans 2 blocs de résultats, à séparer si possible (explications plus bas)

Bloc 1 : les comptes usager correspondant à la recherche (libellé bloc: comptes citoyen)
  • Visu sur la fiche usager (le compte citoyen) et les démarches associées (proche de l'existant)
Bloc 2 : les demandes réalisées sans compte citoyen qui correspondent aux critères de recherche (libellé bloc : Demandes sans compte)
  • éléments pris en compte dans la recherche : nom, prénom, mobile, mail, code de suivi, N° demande (en fait ce qui correspond à la recherche "Texte" dans la vue globale dans l'interface de traitement)
  • ne pas afficher dans ce bloc les démarches qui sont rattachées à un compte, les afficher dans le bloc 1 (?)
  • Visu : catégorie, nom du formulaire, N° demande, nom, prénom, mail, mobile, date demande, statut

Important : Exclure les comptes agents de la recherche sur les citoyens (devraient pouvoir se régler avec la gestion des OU)

  • Cas particulier pour le suivi d'une demande existante (l'usager appelle pour savoir où en est sa demande)
    • Difficultés actuelles : un compte usager n'a pas forcément été créé lors de la demande initiale (il arrive aussi souvent pour les accueils téléphoniques que l'usager n'ait pas de mail) et l'usager n'a pas forcément son code de suivi ou le n° de la demande si sa demande initiale a été faite par téléphone (et n'a souvent aucun moyen de le retrouver).
    • Que font les agents aujourd'hui ? Après avoir vainement essayé de trouver la demande dans Welco, ils vont dans l'interface de traitement et recherche la demande en tapant le nom de l'usager ou son N° de tel dans le bloc "texte" (et donc ils sortent de Welco, ce qui est ergonomiquement pas bon du tout)
    • il faudrait donc pouvoir réaliser cette recherche dans Welco, c'est le sens des deux blocs de résultats mentionnés plus haut.

1/ Si l'agent trouve la fiche usager (= l'usager a un compte)

  • L'agent sélectionne la fiche et remplit un formulaire (un seul, pas la peine d'avoir un "panier de démarches")
  • Les donnés du formulaires sont alors pré-remplies avec celle du compte usager, celles-ci sont modifiables par l'agent, en fonction des infos données par l'usager
  • L'agent doit pouvoir indiquer DANS le formulaire que les informations du compte modifiées devront mettre à jour les données du compte usager (en demandant oralement l'accord à l'usager : celui-ci pouvant recevoir une notification)

2/ Si l'agent ne trouve pas l'usager (= l'usager n'a pas de compte)

  • L'agent peut ou pas créer un compte facilement (avec les référentiels associés)
  • l'agent initie un formulaire correspondant à ce que souhaite l'usager
    => fonctionnement proche de l'existant.

Liste des formulaires

  • Ne lister que les formulaires pour lesquelles l'agent a les droits pour la saisie back-office

Si liaison CTI (Couplage Téléphonie-Informatique)

Fonctionnement comme guichet : recherche manuelle toujours possible mais sur appel entrant, pré-sélection du ou des comptes ayant le n° de tél entrant en donnée du compte

Fonctionnement à prévoir : clic-to-call = initier un appel depuis une fiche usager

la création de compte usager

Objectifs :
  • Rendre plus fluide
  • Rendre plus plus efficace pour l'agent et l'usager
  • Ne pas tout baser sur le mail (certains vieux n'ont pas forcément de mail, les jeunes ne savent même plus ce que c'est !), par contre ils ont quasiment tous un N° de tel mobile;
  • Préserver le consentement explicite de l'usager pour la création de compte avec un processus de validation du compte, par mail mais aussi par SMS
Conséquences importantes sur la création de compte :
  • rendre obligatoire un identifiant +/- unique pour la création du compte : le mail ou le N° de tel mobile
  • interdiction de doublon sur le mail de l'usager lors de la création de compte
  • interdiction de doublon sur le N° de tel mobile lors de la création de compte
    => Cela suppose de fait d'adapter la création de compte actuelle, car on doit par exemple vérifier (en sortie de page ?) la présence obligatoire d'un mail OU d'un n° de mobile

Si aucun de ces éléments n'est disponible (ce qui est rarissime), alors on ne crée pas de compte.

  • Création de compte avec FC
    Concernant la création de compte avec FC, je ne connais pas assez le fonctionnement de FC pour en parler (-> Mik ?)

Sur le contenu de la fiche Usager

Le contenu de la fiche usager en mode "Guichet" devra être revue pour :
  • être orientée agent traitant
  • ne pas exposer des boutons d'action comme dans A2 aujourd'hui qui ne concernent pas les agents traitants
  • être plus lisible

Si on est ok sur le principe, à savoir l'agent traitant doit pouvoir accéder à une fiche usager, je pourrai avancer sur des spec plus détaillées sur la composition de cet écran et sur la réflexion de ce que peut / doit voir un agent.

Sur la base de connaissance

Constat : une utilisation limitée (mais réelle à Grenoble par exemple) : est-ce que c'est parce que ce module ne sert à rien, ou est-ce que c'est parce qu'il est largement perfectible ?

Quelques commentaires sur l'existant :

  • La recherche par mots clés est primordiale, il faut la garder et éventuellement l'améliorer avec un nuage de mots clés.
  • Il faudrait pouvoir catégoriser les fiches, pour les rendre par exemple cohérente avec les catégories des formulaires
  • Mieux associer base de connaissance et démarches : trouver une solution pour pouvoir faire monter des liens vers une fiche lors du traitement d'une demande (ou mieux la fiche elle-même) en fonction de données saisies dans le formulaire. Exemple : les fiches sur le tri des déchets lorsque l'usager fait une demande sur le tri des déchets (infos connues dans le formulaire), ne serait-ce que pour indiquer à l'agent qu"une fiche existe
  • Possibilité d'indexer le contenu des PDF ?

Welco courriers (ou welco mail) : hors scope pour le moment

Questions :
  • Peut-on traiter un courrier entrant sans le rattacher à un compte usager ?
    Brice ?
  • Si la création de compte est obligatoire, comment le rattacher à un compte existant ou comment créer facilement un compte ?
  • Quels sont les éléments obligatoires pour la création de compte (plus haut il est mentionné la présence obligatoire d'un mail ou d'un numéros de mobile)
  • Quid du rattachement à un compte usager dont on ne connait ni le mail, ni le mobile

=> je laisse s'exprimer ici les personnes qui savent de quoi elles parlent


2 Au vu de l'expérience à Grenoble, le point de tension principal n'est finalement pas dû à l'écran Welco mais au fait que les formulaires WCS ne son pas optimisés pour une saisie par le guichet.

  • Un agent peut difficilement passer plusieurs pages pour remplir un formulaire (temps d'attente, aller-retours) alors que son attention est à la fois prise par ce qu'il saisi et par l'usager qu'il a au téléphone ou en face de lui. La logique de WCS interdisant les champs optionnels est particulièrement pénalisante dans le cadre du guichet ; obligeant à passer par des solutions de contournement qui ne sont pas satisfaisantes.

Formats disponibles : PDF HTML TXT