RFC Support

[tchak]

Dans notre feuille de route, nous avons le point suivant : "Faciliter pour l'usager la possibilité de contacter l'administration pour une démarche donnée". Selon moi, le moyen le plus direct d'améliorer la communication avec l'usager est de revoir notre solution de support. Aujourd'hui, l'instance de la DIMUN utilise la solution "helpscout" et "crisp" pour les administrateurs. À ma connaissance les autres instances n'utilisent pas helpscoute et j'ignore comment est géré le support sur ces instances (n'hésitez pas à mettre dans les commentaires les solutions retenues). À la DINUM nous avons une intégration minimale entre l'applicatif métier et la plateforme de support, mais d'une part ce n'est pas suffisant et d'autre part améliorer cette intégration c'est d'investir encore plus dans une plateforme qui n'est utilisée que par nous. De plus, la plateforme helpscout (étant opérée par une entreprise américaine) sera remise en question tôt ou tard. Je pense qu'il serait judicieux d'agir en amont, car si on ne fait rien on nous imposera une solution toute pétée "made in France" ou une solution OSS "usine a gaze".

Ma proposition est d'intégrer la gestion des tickets support directement dans l'application DS. Effectivement, je défends que le support des usagers sur une plateforme de démarches administratives fasse partie du métier. Nous avons déjà le système de messagerie entre les instructeurs et les usagers qui sert à faire du support à l’échelle d’un dossier. Je propose d'étendre cette fonctionnalité à l'ensemble du support.

J'apprécie beaucoup la modélisation de helpscout que je propose de prendre comme base. C'est une modélisation qui dans son itération la plus basique est simple. Je propose d'introduire deux tables : conversations et messages. Un message peut être interne (à l'intention des autres personnes au support) ou externe (fais proprement partie de la conversation). Les messages sont groupés dans les conversations. Les conversations ont un statut (pending, closed, etc.) et ils peuvent être affectés à un agent de support. Les conversations à leur tour peuvent être affectées à un dossier, à une démarche (si la question n'est pas spécifique à un dossier) ou être envoyé dans l’inbox globale de la plateforme. En fonction de l'objet affecté à la conversation, elle sera visible à différents agents de support. Les agents de support peuvent y affecter les conversations à d'autres agents de support au même niveau de hiérarchie (par exemple un "manager" peu affecté à n'importe qui, un “administrateur” à d'autres “administrateur” de la même démarche ou à un des “instructeur" de la démarche, etc.).

Évidemment le prérequis est soit de trouver un prestataire capable de gérer les emails entrants et de les envoyer sur un webhook, soit de configurer notre propre client email sur le serveur pour relever les emails et les piper dans Action Mailbox.

Le fait de migrer vers cette solution interne apportera de nombreuses améliorations :

• résoudra la problématique de protection des données des usagers et du respect de RGPD. Ça va nous tomber dessus si on ne fait rien de toute façon.

• permettra de déléguer les questions métier aux instructeurs en donnant la possibilité aux agents de support de niveau "manager” d'assigner les messages entrants vers les bons dossiers ou démarches, voir destinataires individuels dans certains cas. Il sera aussi possible d'implémenter un système d'escalade de ticket par les instructeurs et administrateurs vers le niveau "manager".

• nous donnera une base pour mieux impliquer les administrations dans le processus de support.

• facilitera l'automatisation de la suppression des conversations expirée.

• les pièces attachées envoyées par email seront stockées dans notre bucket sécurisé et attaché aux dossiers au lieu d'être soit perdu dans les limbes de helpscout soit transférés via des emails non sécurisé et potentiellement perdu.

Alternatives :

Améliorer l'intégration de helpscout ou autre fournisseur choisie. Si l’on veut prendre en considération les besoins des autres instances, on va probablement devoir développer une interface avec des adaptateurs pour différentes solutions de support.

[colinux]

J'ajoute que selon moi, un bon support du point de vue des utilisateurs et des exploitants, devrait tendre vers ces caractéristiques :

• contextuel, aussi bien pour l'utilisateur, que pour le support
• les questions/problèmes les plus fréquents et pas trop tordues doivent pouvoir être répondus directement ou a minima proposer en priorité une solution (ex: "comment changer mon mot de passe",…) via un chatbot, ou un arbre de décision à nous, … Ça peut nécessiter l'internalisation des FAQ. C'est aussi ce qui permet la scalabilité

L'internalisation permet certainement d'aller vers là, mais au prix d'un investissement assez conséquent

[Dan33l]

Merci @tchak d'ouvrir le sujet.

A l'Adullact nous avons fait le choix de ne pas utiliser Helpscout. Et nous essayons de router vers une page FAQ que nous mettons à jour quand cela nous parait utile. Ce processus est ainsi parce que nous ne voulions pas utiliser un service externe payant, qui plus est d'une entreprise US (RGPD). Ce n'est probablement pas le paradis en terme d'assistance, mais nous avons fait avec les moyens du bord.

Dans l'usage de l'Adullact, nous souhaitons que l'utilisateur final puisse, le plus efficacement possible, identifier l'organisme à l'origine de la démarche. Nous avons régulièrement des utilisateurs finaux qui contactent l'Adullact au lieu de contacter l'organisme administrateur de la démarche concernée. Pour cela, par exemple l'organisme et ses coordonnées de contact peuvent être présentes sur toutes les pages du processus (dès l’accueil sans compte DS).

A l'Adullact nous sommes peu de permanents. Ainsi, nous devons économiser les ressources humaines de support. Nous ne souhaitons être sollicité qu'à propos d'un problème sur la plateforme (hébergement par exemple) ou sur une habilitation de haut niveau. Nous cherchons toujours à donner les moyens à nos adhérents collectivités de traiter les sujets puisqu'elles disposent du personnel adéquoit où d'une prestation d'assistance avec une entreprise. Ceci est un point de fonctionnement qui est, au moins pour le moment, très différent de celui de la Dinum qui me parait prendre à sa charge le support.

Je vais décrire maintenant le modèle que nous avons sur S2low.org. C'est une plateforme tier de confiance sur les protocoles ACTES et HELIOS, homologuée par 2 ministères, avec plus de 10000 organismes présents. Soit une collectivité ne prend pas de contrat d'assistance avec une entreprise. Nous mettons le SIRET de la collectivité dans le groupe ADULLACT. Et nous ne faisons pas d'assistance hors mis un problème d'infrastructure, nous mettons à disposition un manuel administrateur et utilisateur (instructeur dans le langage DS). Soit, une collectivité peut prendre un contrat d'assistance avec une entreprise. Nous mettons le SIRET de la collectivité dans le groupe de l'entreprise (entreprise qui doit adhérer à l'association pour pouvoir disposer d'un groupe sur notre plateforme). Et zou, l'entreprise dispose des habilitations pour aider la dite collectivité. Nous pouvons ainsi contrôler qui peut accéder à quoi, tout en donnant accès à de l'aide, sans nous surcharger.