Comment faites-vous face à l'incertitude du courrier électronique ?

Question

Je travaille sur plusieurs processus qui pourraient potentiellement rencontrer des problèmes qui doivent être résolus par des personnes. Actuellement, il consigne ces erreurs et envoie un courriel aux personnes concernées.

Mais l'email semble être le maillon faible ici. Les problèmes que je rencontre sont les suivants : le serveur de messagerie est en panne, l'e-mail est pris dans un filtre anti-spam, l'e-mail "n'est jamais arrivé".

Dois-je intégrer une sorte d'intra-mail et exiger des utilisateurs qu'ils vérifient une autre boîte de réception, ou y a-t-il des choses que je peux faire pour me sentir plus à l'aise avec mes notifications par e-mail ? Puis-je exiger un accusé de réception ouvert ou quelque chose du genre, et si le message n'est pas ouvert, envoyer un nouvel e-mail ? D'autres idées ?

Answer 1

Vous devriez coder pour "le serveur est en panne". Si les e-mails ne peuvent pas être envoyés, vous devez les mettre en file d'attente pour qu'ils soient envoyés dès que possible.

Vous devriez dire explicitement aux utilisateurs que c'est à eux de mettre vos messages sur la liste "pas de spam". Vous ne devriez pas vous soucier du filtre anti-spam.

Le courriel "jamais arrivé" n'est pas très courant dans la pratique, pour autant que vous ayez écrit du code pour les cas où le serveur est hors service.

Enfin, vous pouvez insérer un lien "cliquer pour accuser réception" dans les courriels et renvoyer un courriel toutes les heures jusqu'à ce qu'une notification soit renvoyée.

Answer 2

De nos jours, le courrier électronique a tendance à être beaucoup plus fiable que les personnes qui travaillent avec lui. Vous devez tenir compte du fait que, dans de nombreux cas, les gens trouvent des excuses pour ne pas recevoir un courriel.

A défaut d'avoir un Skynet -où l'ordinateur principal peut envoyer des robots tueurs sur vos cibles, vous êtes essentiellement lié à la livraison par Internet. Vous avez identifié un grand nombre de faiblesses potentielles ; il existe des solutions de contournement pour la plupart d'entre elles, que je vais essayer d'énumérer.

• Tout d'abord, votre application. Je vais supposer qu'elle est suffisamment redondante pour ne jamais être trop basse pour être signalée. Au minimum, vous avez des services de surveillance redondants et fiables.

• Un serveur de messagerie pourrait tomber en panne. OK, alors trouvez-en un deuxième !

• Votre réseau pourrait tomber en panne. Il est déconcertant de constater que cela se produit dans la grande entreprise où je travaille. Des choses importantes sont configurées pour fonctionner sur deux réseaux internes indépendants.

• Si vous n'avez qu'une seule ligne Internet vers le monde extérieur, il y a des chances que votre connexion soit interrompue lorsque vous en avez le plus besoin. Un plan judicieux prévoit des connexions Internet redondantes. En cas d'urgence, votre connexion de secours pourrait être sans fil - UMTS ou GSM ou tout autre nom utilisé dans votre pays.

• Vous avez le choix entre gérer votre propre serveur de courrier interne, distribuer directement sur Internet ou utiliser un service de courrier électronique commercial. Si vos courriers ne sont pas confidentiels, j'envisagerais Google Mail pour l'un des chemins sortants. Il a des temps de fonctionnement assez solides et est bien entretenu. Votre autre serveur de courrier sortant devrait probablement se trouver au sein de votre entreprise.

• Le maillon faible, ce sont vos destinataires. Vous devez être sûr qu'ils reçoivent leurs courriers. Pour déjouer l'excuse du "filtre anti-spam" et les autres, demandez à votre serveur d'envoyer un courrier à toutes les personnes interrogées une fois par semaine et demandez-leur de répondre, en incluant l'objet généré aléatoirement. Cela vous confirmera que, au moins au cours de la semaine précédente, votre destinataire a reçu son courrier. Si ce n'est pas le cas, enquêtez.

• L'envoi d'un courriel dans la boîte aux lettres de vos destinataires n'est pas la seule solution. Une fois que vous êtes sur Internet, il existe des alternatives comme les SMS et les services de radiomessagerie. Ces services vous permettent d'atteindre le téléphone du destinataire. Une fois contacté, il peut téléphoner ou consulter le courrier électronique de son entreprise.

Si vous êtes en train de courir NORAD vous avez peut-être besoin d'une meilleure protection de vos messages. Sinon, l'attention portée aux points ci-dessus rendra votre opération aussi sûre que possible.

Answer 3

J'utilise également des notifications par e-mail, mais je place tous ces messages dans une table de base de données avec un indicateur s'il s'agit d'une importation de données, d'un mauvais mot de passe, etc.

Les utilisateurs, qu'ils soient avertis ou non, peuvent voir ce journal (ou timeline) de la même manière que Trac (logiciel de suivi des bogues) ou Facebook affiche les nouvelles. Il s'agit d'un flux que vous pouvez filtrer selon divers critères.

Certaines personnes pourraient être intéressées par les messages ou erreurs liés à l'importation de données, d'autres par les problèmes d'authentification, etc.

Vous pouvez également envoyer ces notifications par courrier électronique ou créer d'autres "diffuseurs" tels que des messages Jabber/XMPP, des messages Twitter, etc.

Answer 4

Vous pouvez demander à l'utilisateur de cliquer sur un lien inclus dans l'e-mail pour accuser réception de l'e-mail. Les courriels qui n'ont pas fait l'objet d'un accusé de réception au bout d'un certain temps peuvent être renvoyés ou faire l'objet d'une escalade.

Answer 5

J'intégrerais probablement une sorte de page d'état, où tous (ou certains ; cela dépend) de vos utilisateurs pourraient voir toutes les erreurs en suspens. Ainsi, si un courriel n'arrive jamais, il y a toujours une trace de la tâche que l'utilisateur doit accomplir. (du point de vue de la convivialité, il est plus facile pour moi de vérifier une page Web qu'un autre compte de messagerie).

Je pourrais également intégrer une sorte de tâche qui passerait en revue toutes les erreurs en suspens et enverrait un nouvel e-mail à l'utilisateur après un certain nombre de jours. (il est vrai que cette solution nécessite un moyen de marquer les erreurs comme étant résolues ; peut-être mettre en place une boîte aux lettres à laquelle l'utilisateur peut répondre lorsqu'il a reconnu/résolu le problème ; et faire en sorte que quelque chose surveille cela et mette à jour votre table de journal).