Ouvrir un ticket de support

Vous pouvez signaler un problème sans quitter ARDS. Utilisez-le pour tout ce qui semble lourd à passer par email — rapports de bug, « est-ce attendu ? », demandes de fonctionnalités.

Ouvrir un ticket

Cliquez le bouton flottant ? en bas à droite (Aide et support). Il propose deux options : Demander à l'assistant, pour les questions produit, et Signaler un problème, qui ouvre le formulaire de signalement :

Résumé — une courte ligne. « Mission bloquée en Decomposing depuis 3 minutes » est bon. « Ça ne marche pas » ne l'est pas.
Description — ce qu'il s'est passé, ce que vous attendiez, ce que vous avez essayé. Incluez des horodatages approximatifs (pour qu'on retrouve les logs).
Sévérité (facultatif) — Faible / Moyenne / Élevée. Laissez vide si vous hésitez ; on triage tout de toute façon.
Inclure une capture de la page courante — cochez et ARDS capture la page pour vous à l'envoi.
Pièces jointes (facultatif) — ajoutez des fichiers depuis le disque : jusqu'à 20 par signalement, 10 Mo au total. Pour plus gros, passez par email.

Cliquez Envoyer. Le ticket apparaît sur votre page Tickets de support à l'état Received.

Pourquoi l'utiliser plutôt que l'email

Les tickets ouverts dans l'app sont liés à votre tenant, peuvent porter une capture de la page exacte où ça s'est mal passé, et remontent dans votre tableau de bord — vous voyez chaque changement d'état directement, sans aller voir votre boîte de réception.

L'email marche toujours (voir Obtenir de l'aide — support@etiakorp.com). Utilisez l'email quand :

Vous ne pouvez pas vous connecter (donc vous ne pouvez pas ouvrir un ticket).
Vos fichiers dépassent la limite in-app (20 pièces jointes / 10 Mo par signalement).
Le problème touche à la facturation ou à la sécurité et vous préférez ne pas le poser dans le canal habituel.

Et après

On le lit. Les temps de réponse en accès anticipé sont au mieux — entre quelques minutes et quelques jours ouvrés selon le fuseau et la sévérité.

Le ticket traverse des états que vous verrez en badges :

Received — déposé, pas encore pris en charge.
Investigating — quelqu'un (ou une mission d'investigation) regarde.
AwaitingReporter — on a posé une question ; le fil du ticket dit « L'équipe attend votre réponse. » — répondez là.
Confirmed / Fixing — le bug est reproduit, puis en cours de correction.
AwaitingVerification — un correctif est parti, et c'est à vous de trancher : « L'équipe a déployé un correctif. Veuillez vérifier s'il résout votre problème. » avec deux boutons, Confirmer la résolution et Toujours présent. Vous seul, le rapporteur, pouvez fermer cette boucle.
Resolved — vous avez confirmé le correctif.

Un ticket peut aussi se fermer sur un verdict plutôt qu'un correctif : WontFix, CannotReproduce, Misconfiguration, Misuse ou Duplicate — chacun dit pourquoi, pour que l'issue ne soit jamais une fermeture silencieuse.

Tant qu'un ticket est ouvert vous pouvez ajouter du contexte au fil à tout moment ; ça ne change pas l'état.

Anti-patterns

Ne collez pas de secrets. Masquez tout ce qui est sensible dans les captures. On n'a pas besoin de clés d'API ni de jetons pour diagnostiquer — ça complique juste notre rétention.
N'ouvrez pas deux fois le même ticket. Si vous revoyez le bug, ajoutez un message au ticket existant. Plusieurs tickets pour un même bug nous ralentissent.
Ne gonflez pas la sévérité des demandes de fonctionnalité. Ça noie le signal. Laissez la sévérité vide ou Faible ; on lit tout.

Suivi

Votre page Tickets de support liste tous les tickets de votre tenant, filtrables par projet et par état. Chaque ligne montre l'état du ticket, son indice de sévérité, et un badge SLA — Dans les temps, En retard ou Dépassé — pour voir d'un coup d'œil si ça avance. Ouvrir un ticket montre son fil complet, ses pièces jointes, et les missions d'investigation qu'ARDS a lancées pour lui.