Bonjour, Dans mon ancienne boite, nous avions un gros site principal de 1800 pc + un trentaine de sites distants, de taille plus ou moins importante (de 10 à 800 pc). En premier lieu, nous avons défini par GPO une home page sur les navigateurs qui démarrent forcément sur un portail Intranet. Ce portail contient des news à propos de la boutique, des infos drh, le menu des cantines, la météo, un formulaire recherche google, etc.. bref, tout ce qu'il faut pour qu'il soit presque attrayant. Dans ce portail, nous avons la possibilité d'émettre des status très rapidement sur une panne, une maintenance programmée, etc.., tout en indiquant la durée estimée de la panne, et bien sûr, remise à jour régulièrement tout au long de la panne. Ce qui est très important, c'est aussi de remettre un feu vert quand le pb est résolu. C'est un peu contraignant à gérer pendant une galère système/réseau. Aussi, nous avions des modèles de message tout prêts :
Panne de messagerie apparu à hh:mm. Cette panne concerne l’ensemble des services / agences situés ici.. etc.. Rétablissement estimé pour 14h30 Détail : vous ne pouvez plus recevoir ou émettre de messages. Les mails envoyés vous seront délivrés plus tard, etc. Cela allège énormément la hotline et éduque les utilisateurs. Sinon, pour communiquer de façon plus instantanée, soit tu a un XMPP/Jabber/Skype déja installé dans ta boutique (mais pas forcément lancé par l'utilisateur), soit tu peux prendre un outil qui fait apparaître un "popup" sur l'écran de tes utilisateurs : nous avons acheté l'outil dmessage (désolé pour la pub..) qui permet d'avertir de façon urgente en cas d'alerte confinement/terrorisme/évacuation etc.. Je n'ai malheureusement aucun recul sur ce produit car j'ai quitté la société avant l'installation du produit, mais c'est ce qui me semblait le plus intéressant. Tu peux trouver des softs équivalents : - SNARL : http://snarl.fullphat.net/ - YAD : open source (https://sourceforge.net/projects/yad-dialog/ ) Ce genre d'outil peut d’ailleurs se faire coder par un stagiaire en dev. Avec un peu de réfléchissement et de bon sens, on peut vite faire un Exe qui écoute sur un port particulier et qui est capable d'afficher un message reçu (soit par broadcast, soit par push/pull). Par exemple, un process sur le pc écoute un port particulier, en attente d'un message. Le serveur/ Pc du rédacteur a un process qui peut envoyer le message/trame à tous les clients. Pour éviter le broadcast qui passe pas les routeurs, tu peux imaginer que le poste serveur tient à jour une liste des pc clients qui se signalent up toutes les 5mn. Et puis, si ta topologie réseau ne te permet pas de joindre tous les pc, alors, tu imagine un répertoire de dépot (un partage, une URL, etc..) que les clients scruteront régulièrement pour y trouver un message à afficher. Enfin, si tes utilisateurs sont en Citrix/TSE, rien de plus facile que d'envoyer un message sur toutes les sessions. (attention cependant à l'afficher plusiuers fois, car certains users-gros-nazes cliquent sur ok sans même lire le message. Cas rencontré de nombreuses fois ! Olivier. Le 26 septembre 2017 à 10:08, Analogx via FRsAG <frsag@frsag.org> a écrit : > Bonjour, > > Merci à tous pour vos retours, je pense en effet que notre salut viendra > de la téléphonie et peut etre d'un SVI. > Avez-vous connaissance de système capable également de générer des appels > audio sortants automatiques à partir d'un message synthétisé ? > > > > > -------- Original Message -------- > Subject: RE: [FRsAG] Comment informer nos utilisateurs multi-sites > Local Time: 25 septembre 2017 11:15 AM > UTC Time: 25 septembre 2017 09:15 > From: x.r...@sipleo.com > To: 'Analogx' <anal...@protonmail.com> > frsag@frsag.org, 'Guillaume' <gui...@gmail.com> > > Bonjour, > > > > Un SVI comme le propose Guillaume me semble bien approprié. > > Uniquement activé sur incident par un script ou manuellement. > > Message par TTS (synthèse vocale) expliquant l’incident etc.. > > Le tout couplé à un Helpdesk qui fait le job et plus. > > Remonté de fiche en temps normal aussi pour plus d’efficacité. > > Si dans le message, on les incite le plus souvent possible à prendre > l’habitude du helpdesk … > > Après on peut ajouter du routage d’appel dynamique. > > Aussi un appel de type avertissement vocale a certains utilisateurs ayant > le rôle de correspondant > > Et bien autres fonctions… > > > > C’est ce que l’on propose régulièrement à des clients multisites dans ce > cas avec notre offre Sipleo et Visione. > > > > Xavier > > > > *De :* Guillaume [mailto:gui...@gmail.com] > *Envoyé :* lundi 25 septembre 2017 00:36 > *À :* Analogx <anal...@protonmail.com> > *Cc :* frsag@frsag.org > *Objet :* Re: [FRsAG] Comment informer nos utilisateurs multi-sites > > > > Bonsoir, > > > > Cela devrait dépendre du système employé pour la communication actuelle. > Si dans ton cas il s'agît du téléphone il semblerait évident de déposer un > système de messagerie en effet. > > > > Un menu qui se mettrait en place en précisant s'il s'agît d'un soucis > concernant le problème: > > > > "description du problème en cours" nos équipes sont déjà au courant et > tentent de le rétablir au plus vite. Et vous pouvez avoir des informations > également sur notre page interne "http://status.notresupersite.com > > > > ". bla bla bla. > > Si votre demande concerne un autre sujet appuyez sur la touche 1 ou bien > restez en ligne. > > > > Ou alors sensibiliser par une petite campagne d'email ou bien une > éventuelle formation sur place chez le client à l'utilisation d'un lien > vers une page de statuts des services plus informations si nécessaire. > > > > Après si le moyen de communication est un système de ticketing dans ce cas > d'autres options peuvent être déployées, réponses automatiques suite à une > analyse de mots clés, pré-filtrer les demandes selon des cas incluant les > cas urgents à traiter en cours. > > > > Penser à déployer un module lié à l'ERP en question ou bien pour d'autres > motifs un logiciels déployable sur les postes qui permettrait de fournir > des informations via un canal de push sur l'état en cours. > > > > Se connecter chez les clients si ils sont déjà équipés à leur système de > monitoring interne pour y insérer une alerte sur mesure. > > > > Installer chez les clients des écrans de monitoring avec l'état en cours > des services peut être avec une petit système embarqué qui saurais aller > récupérer l'information via une API. > > > > Je suis curieux d'avoir d'autres retours également, > > > > Cordialement, > > Guillaume > > > > Le 24 septembre 2017 à 21:04, Analogx via FRsAG <frsag@frsag.org> a écrit > : > > Bonsoir, > > > > Voici ma problématique : > > > > Nous exerçons pour une société qui a de nombreux sites distants (40) et > les utilisateurs de ces sites utilisent tous le même système (ERP) hébergé > en cœur de réseau (cloud privé). > > > > Lorsque nous rencontrons un incident (majeur ou pas), la quasi majorité > des utilisateurs appelle le support informatique pour expliquer son > problème. > > > > Ce qui bien entendu a tendance a le saturer et l’empêche de traiter > rapidement le problème. > > > > Je cherche un donc un outil ou une méthode qui nous permettrait de > prévenir les utilisateurs de ces dysfonctionnements. > > Même si j’ai déjà pensé au message sur La boîte vocale, je ne trouve pas > cela efficace . > > > > Merci pour vos retours d’expérience . > > > > Ana logx. > > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > > > > > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
