Objectif
Standardiser le traitement des incidents et demandes dans Autotask :
- Création/tri (email → ticket)
- Qualification (impact, urgence, catégorie)
- Respect SLA (priorités, escalade)
- Traçabilité (notes, pièces jointes, time entries)
- Clôture propre (résolution, communication, post-mortem léger)
Hypothèse : votre tenant Autotask est connecté à la boîte support (création auto de tickets à partir des emails). Si ce n’est pas le cas, adaptez l’étape 1 (intake).
Étape 1 — Intake : de l’email au ticket
- Ouvrez Autotask.
- Menu principal → Service Desk → Tickets.
- Filtrez par file/queue :
N1 - Support(ou équivalent). - Vérifiez que l’email reçu a bien généré un ticket :
- Sujet email → titre du ticket
- Corps email → description / note initiale
- Pièces jointes → onglet Attachments
Bonnes pratiques
- Une adresse unique :
support@... - Un objet email explicite :
[Client] - [Service] - [Symptôme] - Un champ Company / Contact correctement mappé (sinon le faire dès la qualification).
Étape 2 — Qualification (3 minutes max)
Ouvrez le ticket et complétez immédiatement :
- Company / Contact (client + demandeur)
- Type : Incident / Service Request / Problem
- Catégorie / Sous-catégorie (ex. Sécurité → Antivirus / Web Filtering)
- Impact (1 utilisateur / équipe / site / prod)
- Urgence (bloquant / dégradé / mineur)
- Priorité (calculée ou manuelle selon votre modèle)
- Source (Email, Phone, Monitoring, etc.)
Mini grille Impact × Urgence (exemple)
- Impact élevé + Urgence élevée → P1
- Impact élevé + Urgence moyenne → P2
- Impact moyen + Urgence élevée → P2
- Impact moyen + Urgence moyenne → P3
- Tout le reste → P4
Étape 3 — SLA : timers et escalade
- Vérifiez le champ SLA appliqué (souvent auto via Company).
- Contrôlez la Due Date et/ou les jalons (First Response / Resolution).
- Si P1/P2 :
- Assignez immédiatement à un technicien
- Ajoutez un tag/flag “On-call” si existant
- Prévenez via canal interne (Teams/Slack) selon runbook
Anti-bruit
- P1 réservé au vrai “business down”
- Requalifier dès que vous avez des éléments (évite les escalades inutiles)
Étape 4 — Traitement : notes, actions et time entries
4.1 Notes (communication)
- Note interne : pour l’équipe (diagnostic, hypothèses, next steps)
- Note client : claire, factuelle, sans jargon inutile
Structure recommandée (copier-coller)
- Symptôme :
- Constat :
- Actions effectuées :
- Résultat :
- Prochaine étape / ETA (si applicable) :
4.2 Time Entry (obligatoire)
- Cliquez New Time Entry (ou équivalent).
- Renseignez :
- Date / Start / End
- Work Type (Remote/On-site)
- Summary Notes (résumé actionnable)
- Sauvegardez.
Un ticket sans time entry devient “inexploitable” (facturation, reporting, amélioration continue).
Étape 5 — Escalade N2 / vendor
5.1 Quand escalader
- Vous avez identifié un périmètre hors N1
- Vous avez reproduit / collecté les preuves (logs, captures)
- Vous avez tenté les actions standard (runbook N1)
5.2 Pack d’escalade (à mettre dans le ticket)
- Contexte : client, site, impact
- Horodatage + fréquence
- Logs pertinents / captures
- Actions déjà tentées (et résultat)
- Hypothèse + question précise
Ensuite :
- Changez l’Assigned Resource vers
N2(ou queue dédiée). - Ajoutez une note interne “ESCALADE” + pack.
- Si vendor (ex. Webroot/Malwarebytes/Microsoft) :
- Créez un case vendor
- Ajoutez l’ID du case dans le ticket
Étape 6 — Clôture (qualité)
Avant de fermer :
- Vérifiez qu’une résolution est saisie (champ Resolution).
- Vérifiez qu’un compte-rendu client est envoyé (note client ou email).
- Vérifiez qu’il y a :
- au moins 1 time entry
- les pièces jointes utiles
- Passez le ticket en Complete / Closed.
Étape 7 — Post-mortem léger (si P1/P2)
Ajoutez une note interne “RETEX” :
- Cause racine (si connue)
- Mesure corrective
- Mesure préventive (monitoring, policy, documentation)
- Action à créer (task) si nécessaire
